A jornada de reserva 2: conversas entre canais e motores [Infográfico]
Motor de Reservas 12/11/2019
Em A jornada da reserva 1: do Fax ao XML 2.0 , o primeiro artigo da saga particular criada por Nacho Marín, Lead Developer da Paraty Tech, foi concluído com grande promessa. Esta segunda parcela aspira cumpri-lo.
Com The Booking Journey 2: Conversas entre canais e motores , pretendi dirimir todas aquelas dúvidas que recebo diariamente em relação à forma como os gestores de canais e os motores de reservas comunicam. Para fazer isso, decidi unificá-los em duas questões fundamentais:
Ao respondê-las, espero também ajudá-lo a descobrir qual channel manager é mais adequado para o seu mecanismo de reservas. A pergunta de um milhão de dólares...
Dito isto, como ponto de partida, penso que o melhor é categorizar cada tipo de ligação com base em três aspectos fundamentais:
Infográfico Paraty Tech, Canais vs. Motores, Qual é o melhor para você?
Para ser sincero, o formato dos arquivos trocados, como tal, não tem importância na hora de escolher um ou outro channel manager, pois é um fator puramente informático. No entanto, considero importante explicar quais são os tipos fundamentais de formatos e como interpretá-los, pois muitas vezes você se verá incluído, em cópia, em cadeias de e-mail nas quais trafegam esses tipos de arquivos, como anexos, e isso é possível que as informações nele contidas sejam do seu interesse.
A maioria dos gerenciadores de canais compartilha e recebe informações no que é conhecido como arquivo XML . Este arquivo, embora possa ser visualmente pouco atraente, é relativamente fácil de entender por um ser humano sem conhecimento de programação. Além disso, tem uma vantagem: os navegadores (Explorer, Chrome, Firefox, Safari, Opera, etc.) sabem lê-los e irão ajudá-lo a interpretá-los, colorindo-os e permitindo abrir e fechar seus elementos.
Abaixo mostro um exemplo de fragmento de um arquivo XML típico:
Outro formato comum, do qual você provavelmente já ouviu falar apesar de ser menos comum, é o Arquivo JSON , que teria uma estrutura como a mostrada abaixo:
Outro ponto muito interessante, que deve ter em consideração, é o que diz respeito à comunicação que se estabelece entre os motores e os gestores de canal no momento do download das reservas. Embora possa não ser suficientemente decisivo para determinar a decisão de optar por um ou outro fornecedor, é fundamental compreender quais são as duas formas que os gestores de canal dispõem para recuperar todas as reservas efetuadas através dos diferentes pontos de venda online.
Desta forma, seremos capazes de distinguir onde está o problema quando uma reserva demorou mais do que o desejado para ser despejada ou, na pior das hipóteses, nem sequer o fez. Da mesma forma, estaremos mais preparados para lidar com as explicações fornecidas, a este respeito, pelos diferentes suportes técnicos envolvidos no processo em questão.
Assim, do ponto de vista dos motores, existem duas formas de enviar reservas:
Envio de reservas pull
Ao enviar reservas do tipo Pull, é o channel manager quem solicita, a cada x minutos, a lista de reservas realizadas naquele dia. Essa solicitação é chamada de ação pull.
A favor deste tipo de comunicação, é preciso dizer que é muito difícil uma reserva não ser enviada devido a uma falha específica (por exemplo, um servidor fora do ar), uma vez que a lista de reservas vai sendo solicitada ao longo do dia.
Por outro lado, o download das reservas não é imediato. Por exemplo, se o gestor do canal os solicitar a cada 10 minutos, uma reserva pode demorar, no máximo, esse tempo a ser integrada.
Envio de reservas push
Contrariamente ao comportamento descrito, no envio de reservas do tipo Push, as reservas são enviadas imediatamente após serem efetuadas, sem tempos de espera, minimizando a probabilidade de possíveis situações de overbooking.
Utilizando novamente a hipótese de servidor inativo, a principal desvantagem deste tipo de comunicação é que, se um sistema de nova tentativa não for configurado, a reserva terá um pouco mais de probabilidade de ser perdida.
Na Paraty Tech, caso seja registrado algum erro, solucionamos esse tipo de incidente reenviando a reserva em até quatro vezes. Se mesmo após a quarta tentativa não conseguirmos obter o OK do gestor do canal, enviamos emails de alerta para que a reserva possa ser gerida manualmente.
Agora, vamos direto ao que considero o aspecto mais importante na hora de decidir sobre um ou outro channel manager. Para tal, explicarei os dois tipos de ligação existentes, no que diz respeito à comunicação do estado de disponibilidade, restrições e preço. Mais uma vez, como quase sempre acontece na vida, cada uma delas tem seus prós e contras. Entramos assim no complexo mundo dos Canais Pull e dos Canais Push.
Puxar canais
Este tipo de canal oferece, em tempo real, preços e disponibilidade. Ou seja, sempre que é realizada uma pesquisa numa página web (por exemplo, no canal oficial de vendas do hotel), o motor de busca envia um pedido ao canal, e este responde com preços e disponibilidade.
Estes tipos de conexões têm a vantagem de serem geralmente mais fáceis de configurar, pois todos os detalhes do produto são carregados em um único painel de controle. Em teoria, isso deveria reduzir o risco de erros com menos sistemas envolvidos. Além disso, pelo mesmo motivo, também deverá ser mais fácil localizar um erro, por exemplo, no cálculo de um preço.
Pero, a veces, las fortalezas pueden ser también entendidas como debilidades, y su desventaja principal deriva, precisamente, de su propia naturaleza: al estar todo centralizado en un sistema único (el channel), todos los motores con los que esté conectado, dependen do mesmo.
O Channel Pull costuma ser acompanhado de buscas mais lentas, pois o mecanismo deve primeiro enviar uma solicitação (Request), depois aguardar a resposta (Response) e, uma vez obtida, processá-la para mostrá-la ao cliente.
Outro problema muito comum no Pull de Canais é a possível perda do status de disponibilidade, e o motivo é muito simples. Basta que os servidores do canal caiam, que ele deixe de oferecer disponibilidade em todos os motores aos quais está conectado, sem que ninguém possa fazer nada a respeito.
Por último, e na minha opinião, a desvantagem mais importante do Channels Pull é a sua falta de flexibilidade. O hotel não terá outra escolha senão limitar-se às funcionalidades oferecidas pelo canal. Que o canal não aceita a opção de promocode? Então será muito difícil para o mecanismo de busca do seu site implementá-los. E assim com tudo.
Aspirando, como sempre, a continuar construindo possíveis pontes de colaboração, o que envolve tentar resolver limitações como a que acabamos de descrever, na Paraty Tech desenvolvemos uma camada intermediária que intercepta os preços do canal antes de exibi-los, o que nos permite aplicar uma lógica diferente para eles. Infelizmente, isso nem sempre é possível devido às medidas de segurança deste tipo de canais, que normalmente incluem a verificação do preço, e no momento da submissão da reserva esta poderá ser rejeitada se o preço não corresponder. E mesmo que não fosse assim, o simples facto de ter duas lógicas carregadas em locais diferentes aumenta a complexidade do sistema, o que vai de encontro com aquilo que constitui a principal força do Channels Pull: a sua simplicidade de configuração e simplicidade de conexão.
Envio de canais
Este tipo de canal mantém atualizados os preços, restrições e disponibilidade dos painéis aos quais se conecta. Normalmente comunica-se com os motores de busca sempre que há uma alteração (cota, preço, etc.) ou periodicamente, a cada determinado intervalo de tempo. Ou seja, existem estruturas idênticas e paralelas carregadas em todos os sistemas que estão interligados.
Por este motivo, os diferentes sites que estão ligados a um Channel Push oferecerão sempre disponibilidade, independentemente de o canal sofrer um apagão, uma vez que todo o produto será pré-carregado (e atualizado até o referido apagão) nos outros sistemas, que funcionam independentemente do canal.
Além disso, a rapidez na apresentação da disponibilidade nos diferentes sites é muito superior à dos Canais Pull, uma vez que não requer qualquer tipo de comunicação entre os dois sistemas.
Por último, também oferecerá maior flexibilidade, pois por ter preços pré-carregados, permitirá incorporar ofertas sofisticadas, criar pacotes, utilizar códigos promocionais, implementar tarifas com estruturas complicadas, etc. Tudo isso, independentemente de o canal suportar ou não essas funcionalidades.
Mas então, quais são as desvantagens de um Channel Push? Em suma, fundamentalmente dois. Por um lado, a configuração inicial envolverá mais trabalho devido aos famosos mapeamentos, possuindo estruturas paralelas carregadas em ambos os lados, o que obriga a haver uma correlação entre os diferentes códigos internos.
Por outro lado, resolver incidentes pode ser um pouco mais tedioso. Ter preços carregados em vários painéis pode dificultar a identificação do ponto exato onde o problema ocorreu, exibindo o preço errado ou a disponibilidade errada.
A este respecto, y ya para terminar, en Paraty Tech hemos implantado un software de auditoría que nos permite recuperar el histórico XML enviado por los Channels Push, y conocer así el día concreto y la hora exacta en la que recibimos un precio, restricción o vaga.
Com The Booking Journey 2: Conversas entre canais e motores , pretendi dirimir todas aquelas dúvidas que recebo diariamente em relação à forma como os gestores de canais e os motores de reservas comunicam. Para fazer isso, decidi unificá-los em duas questões fundamentais:
- Quais variantes de Channel Managers estão disponíveis no mercado?
- Que vantagens e desvantagens eles têm?
Ao respondê-las, espero também ajudá-lo a descobrir qual channel manager é mais adequado para o seu mecanismo de reservas. A pergunta de um milhão de dólares...
Dito isto, como ponto de partida, penso que o melhor é categorizar cada tipo de ligação com base em três aspectos fundamentais:
- O formato dos arquivos trocados
- A forma como as reservas são baixadas
- A forma como os preços e a disponibilidade são trocados
Infográfico Paraty Tech, Canais vs. Motores, Qual é o melhor para você?
1. Gestores de canais com base no formato dos arquivos trocados
Para ser sincero, o formato dos arquivos trocados, como tal, não tem importância na hora de escolher um ou outro channel manager, pois é um fator puramente informático. No entanto, considero importante explicar quais são os tipos fundamentais de formatos e como interpretá-los, pois muitas vezes você se verá incluído, em cópia, em cadeias de e-mail nas quais trafegam esses tipos de arquivos, como anexos, e isso é possível que as informações nele contidas sejam do seu interesse.
A maioria dos gerenciadores de canais compartilha e recebe informações no que é conhecido como arquivo XML . Este arquivo, embora possa ser visualmente pouco atraente, é relativamente fácil de entender por um ser humano sem conhecimento de programação. Além disso, tem uma vantagem: os navegadores (Explorer, Chrome, Firefox, Safari, Opera, etc.) sabem lê-los e irão ajudá-lo a interpretá-los, colorindo-os e permitindo abrir e fechar seus elementos.
Abaixo mostro um exemplo de fragmento de um arquivo XML típico:
Outro formato comum, do qual você provavelmente já ouviu falar apesar de ser menos comum, é o Arquivo JSON , que teria uma estrutura como a mostrada abaixo:
2. Gerentes de canal atendendo ao download de reservas
Outro ponto muito interessante, que deve ter em consideração, é o que diz respeito à comunicação que se estabelece entre os motores e os gestores de canal no momento do download das reservas. Embora possa não ser suficientemente decisivo para determinar a decisão de optar por um ou outro fornecedor, é fundamental compreender quais são as duas formas que os gestores de canal dispõem para recuperar todas as reservas efetuadas através dos diferentes pontos de venda online.
Desta forma, seremos capazes de distinguir onde está o problema quando uma reserva demorou mais do que o desejado para ser despejada ou, na pior das hipóteses, nem sequer o fez. Da mesma forma, estaremos mais preparados para lidar com as explicações fornecidas, a este respeito, pelos diferentes suportes técnicos envolvidos no processo em questão.
Assim, do ponto de vista dos motores, existem duas formas de enviar reservas:
Envio de reservas pull
Ao enviar reservas do tipo Pull, é o channel manager quem solicita, a cada x minutos, a lista de reservas realizadas naquele dia. Essa solicitação é chamada de ação pull.
A favor deste tipo de comunicação, é preciso dizer que é muito difícil uma reserva não ser enviada devido a uma falha específica (por exemplo, um servidor fora do ar), uma vez que a lista de reservas vai sendo solicitada ao longo do dia.
Por outro lado, o download das reservas não é imediato. Por exemplo, se o gestor do canal os solicitar a cada 10 minutos, uma reserva pode demorar, no máximo, esse tempo a ser integrada.
Envio de reservas push
Contrariamente ao comportamento descrito, no envio de reservas do tipo Push, as reservas são enviadas imediatamente após serem efetuadas, sem tempos de espera, minimizando a probabilidade de possíveis situações de overbooking.
Utilizando novamente a hipótese de servidor inativo, a principal desvantagem deste tipo de comunicação é que, se um sistema de nova tentativa não for configurado, a reserva terá um pouco mais de probabilidade de ser perdida.
Na Paraty Tech, caso seja registrado algum erro, solucionamos esse tipo de incidente reenviando a reserva em até quatro vezes. Se mesmo após a quarta tentativa não conseguirmos obter o OK do gestor do canal, enviamos emails de alerta para que a reserva possa ser gerida manualmente.
3. Gestores de canal atendendo à comunicação de disponibilidade e preço
Agora, vamos direto ao que considero o aspecto mais importante na hora de decidir sobre um ou outro channel manager. Para tal, explicarei os dois tipos de ligação existentes, no que diz respeito à comunicação do estado de disponibilidade, restrições e preço. Mais uma vez, como quase sempre acontece na vida, cada uma delas tem seus prós e contras. Entramos assim no complexo mundo dos Canais Pull e dos Canais Push.
Puxar canais
Este tipo de canal oferece, em tempo real, preços e disponibilidade. Ou seja, sempre que é realizada uma pesquisa numa página web (por exemplo, no canal oficial de vendas do hotel), o motor de busca envia um pedido ao canal, e este responde com preços e disponibilidade.
Estes tipos de conexões têm a vantagem de serem geralmente mais fáceis de configurar, pois todos os detalhes do produto são carregados em um único painel de controle. Em teoria, isso deveria reduzir o risco de erros com menos sistemas envolvidos. Além disso, pelo mesmo motivo, também deverá ser mais fácil localizar um erro, por exemplo, no cálculo de um preço.
Pero, a veces, las fortalezas pueden ser también entendidas como debilidades, y su desventaja principal deriva, precisamente, de su propia naturaleza: al estar todo centralizado en un sistema único (el channel), todos los motores con los que esté conectado, dependen do mesmo.
O Channel Pull costuma ser acompanhado de buscas mais lentas, pois o mecanismo deve primeiro enviar uma solicitação (Request), depois aguardar a resposta (Response) e, uma vez obtida, processá-la para mostrá-la ao cliente.
Outro problema muito comum no Pull de Canais é a possível perda do status de disponibilidade, e o motivo é muito simples. Basta que os servidores do canal caiam, que ele deixe de oferecer disponibilidade em todos os motores aos quais está conectado, sem que ninguém possa fazer nada a respeito.
Por último, e na minha opinião, a desvantagem mais importante do Channels Pull é a sua falta de flexibilidade. O hotel não terá outra escolha senão limitar-se às funcionalidades oferecidas pelo canal. Que o canal não aceita a opção de promocode? Então será muito difícil para o mecanismo de busca do seu site implementá-los. E assim com tudo.
Aspirando, como sempre, a continuar construindo possíveis pontes de colaboração, o que envolve tentar resolver limitações como a que acabamos de descrever, na Paraty Tech desenvolvemos uma camada intermediária que intercepta os preços do canal antes de exibi-los, o que nos permite aplicar uma lógica diferente para eles. Infelizmente, isso nem sempre é possível devido às medidas de segurança deste tipo de canais, que normalmente incluem a verificação do preço, e no momento da submissão da reserva esta poderá ser rejeitada se o preço não corresponder. E mesmo que não fosse assim, o simples facto de ter duas lógicas carregadas em locais diferentes aumenta a complexidade do sistema, o que vai de encontro com aquilo que constitui a principal força do Channels Pull: a sua simplicidade de configuração e simplicidade de conexão.
Envio de canais
Este tipo de canal mantém atualizados os preços, restrições e disponibilidade dos painéis aos quais se conecta. Normalmente comunica-se com os motores de busca sempre que há uma alteração (cota, preço, etc.) ou periodicamente, a cada determinado intervalo de tempo. Ou seja, existem estruturas idênticas e paralelas carregadas em todos os sistemas que estão interligados.
Por este motivo, os diferentes sites que estão ligados a um Channel Push oferecerão sempre disponibilidade, independentemente de o canal sofrer um apagão, uma vez que todo o produto será pré-carregado (e atualizado até o referido apagão) nos outros sistemas, que funcionam independentemente do canal.
Além disso, a rapidez na apresentação da disponibilidade nos diferentes sites é muito superior à dos Canais Pull, uma vez que não requer qualquer tipo de comunicação entre os dois sistemas.
Por último, também oferecerá maior flexibilidade, pois por ter preços pré-carregados, permitirá incorporar ofertas sofisticadas, criar pacotes, utilizar códigos promocionais, implementar tarifas com estruturas complicadas, etc. Tudo isso, independentemente de o canal suportar ou não essas funcionalidades.
Mas então, quais são as desvantagens de um Channel Push? Em suma, fundamentalmente dois. Por um lado, a configuração inicial envolverá mais trabalho devido aos famosos mapeamentos, possuindo estruturas paralelas carregadas em ambos os lados, o que obriga a haver uma correlação entre os diferentes códigos internos.
Por outro lado, resolver incidentes pode ser um pouco mais tedioso. Ter preços carregados em vários painéis pode dificultar a identificação do ponto exato onde o problema ocorreu, exibindo o preço errado ou a disponibilidade errada.
A este respecto, y ya para terminar, en Paraty Tech hemos implantado un software de auditoría que nos permite recuperar el histórico XML enviado por los Channels Push, y conocer así el día concreto y la hora exacta en la que recibimos un precio, restricción o vaga.
